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technologies. With information obtained from this experiment, a discrete event 
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then enhanced to include realistic variability for all processes. In addition, further 
enhanced models were created to simulate likely equipment failures and weather delays 
in order to estimate how long the process would take given these various conditions. The 
addition of delays to the model resulted in more realistic cycle times giving the project 
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research community a realistic analysis tool for assessing the process of setting up and 
employing a damage assessment system following a disaster and the results give an 
expected completion time and range under the conditions modeled. 
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I. 


INTRODUCTION 


Given the high number of disasters over the past decade both at home and abroad, 
a great deal of attention has been given to the study of Disaster Relief/Humanitarian 
Assistance (DR/HA), likely due to heightened levels of global awareness made possible 
through advances in communication technology. 

Within the first 24 hours following a disaster, a myriad of activities must occur, 
activities such as search and rescue operations, triage and emergency medical services, 
and the maintenance of civil order and public safety. One common thread among all of 
these activities is that they are time sensitive and require timely information to support a 
great deal of coordination across multiple agencies. 

The specific problem addressed in this project, which was prevalent during 
Hurricane Katrina, is the lack of surveillance and damage assessment systems that can be 
quickly deployed and efficiently employed, functioning independently from any existing 
systems, and providing reliable communications for information gathering and 
coordination during this critical period. This type of system could provide emergency 
and relief agencies a common operational picture, exponentially increasing their 
situational awareness and, in turn, making it possible to provide more efficient support to 
the victims. Without this new found awareness, relief agencies will not know where to 
respond, what personnel, equipment and supplies are needed, or what needs to be 
procured. Though most governments, local or national, do have departments established 
to handle such crises, most do not have a “plan B” in the event the existing 
communications infrastructure is destroyed. For underdeveloped countries such as Sri 
Lanka, Cambodia, Pakistan, Indonesia, and Thailand, who lack a robust infrastructure 
and readily available resources, a system such as this could potentially save thousands of 
lives that may have otherwise been lost. 

In May 2008, the Cooperative Operations and Applied Science and Technologies 
Studies (COASTS) team conducted a live experiment using a data collection system 
aimed at filling the previously mentioned “awareness gap” following a disaster. The 
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system was comprised of numerous commercial off-the-shelf (COTS) technologies which 
were fielded and operated by Naval Postgraduate School (NPS) students with the aid of 
technology representatives. The COASTS experiment was used to test and demonstrate 
the capabilities and value of an independent damage assessment system, consisting of 
multiple individual technologies, being employed following a tsunami with an end goal 
of sending a comprehensive damage report from the Joint Operations Command Center 
(JOCC) to all the agencies that require it. 

The May experiment was based on a post tsunami scenario script developed by 
the COASTS team. The experiment was preceded by numerous test runs the week prior 
to ensure the conditions were set for a successful test. During these practice runs, it 
became very apparent that the system had to be employed in favorable conditions and 
factors such as high winds, heavy rain, or random equipment failures such as power 
outages significantly degraded the data collection systems perfonnance. Despite the 
setbacks during the test runs, COASTS was able to conduct a successful live simulation 
and determined that the data collection system was effective and capable of completing 
the mission. 

Live simulation experiments are inherently limited, since they can only be carried 
out a small number of times. The COASTS experiment was no exception as the full 
simulation was only run once. Therefore, random factors such as weather, climate, 
geography and random failures of personnel and equipment were only represented by a 
single data point in the one simulation run. This makes it impossible to understand the 
effects of these factors on the perfonnance of the system. It is for this very reason that 
discrete-event simulation (DES) modeling is such an excellent resource. 

The value of using DES modeling lies in the fact that the parameters and inputs of 
the system being tested can be altered over multiple simulation runs. By altering these, it 
allows for that system to then be tested under a whole host of situations, in turn giving the 
researcher an ideal of how the system might perform given those conditions. 
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The primary goal of this project is to expand on the COASTS experiment and 
explain how the data collection system would operate under more realistic conditions. 
This is done by first building a model based on the COASTS script using discrete event 
simulation modeling software and information obtained from the COASTS experiment. 
Using the Script Model as a template, a Baseline Model is then created by changing the 
activity times that were constant in the Script Model to activity times drawn randomly 
from a probability distribution to reflect more realism and variability. The Baseline 
Model is then enhanced to reflect possible equipment failures as well as delays due to 
inclement weather. The results of these models are summarized and analyzed and 
recommendations are made. 

Looking ahead, Chapter II provides a background of COASTS to include 
additional information on the problem, a description of the live experiment, and 
characteristics of system equipment. Chapter III describes the simulation model and how 
it was built, states the model assumptions, and illustrates the creation of the Script and 
Baseline Models. Chapter IV explains how the experimental models were created and is 
the precursor to Chapter V which provides results and analysis of the experimental 
models. Finally Chapter VI summarizes the project, conclusions and recommendations. 
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II. RESEARCH BACKGROUND 


This chapter provides the background information about the COASTS 
organization. The chapter then touches on the description and setting for the COASTS 
live experiment, to include a brief description of the data collection system and 
equipment tested. The chapter wraps up with a short summary of the tsunami script 
followed by the COASTS experiment results. 

A. THE COASTS ORGANIZATION 

COASTS is a research based, NPS affiliated, student run organization. Founded 
in 2004 by NPS Research Professors Brian Steckler and James Ehlert, COASTS 

organizes and executes live experiments to demonstrate the capabilities of 
low cost, state-of-the-art, unclassified networked air, ground, and maritime 
equipment for the purposes of providing real time information to tactical 
and remote decision makers. The COASTS team emphasizes the use of 
COTS technologies using tailored scenarios to test and evaluate areas of 
research that are critical to both U.S. and international security objectives. 

In FY2008, the COASTS objectives encompassed field experimentation 
and technology demonstrations in the U.S., Thailand, Malaysia, 
Singapore, and Indonesia. 1 

B. DESCRIPTION OF LIVE EXPERIMENT 

The location chosen by COASTS to conduct the live experiment in May of 2008, 
also known as field experiment V (FEXV), was Prachuap Khiri Khan, Thailand, on a 
Royal Thai Air Force (RTAF) base which is home to Wing 5 (Figure 1). The base is 
located in Ao Manao Bay which is southeast of Prachuap Khiri Khan, on the Gulf of 
Thailand (Figures 1&2). Wing 5 includes an RTAF AU-23 Monoplane squadron and 
hosted the experiment. Wing 5 conducted numerous coordination meetings with 
COASTS and provided a large portion of the requisite personnel and equipment support 
for the experiment. From the COASTS side, approximately 80 personnel, including the 


1 Taken from COASTS 2008 Mission Power Point Brief dated 3 October 2007. 
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author, attended the May experiment ranging from NPS students and faculty, Department 
of Defense personnel, civilian contractors, and representatives from the Office of the 
Secretary of Defense. 
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Figure 1. Map of Thailand Showing Prachuap Khir Khan, the Experiment Site on 

the Gulf Coast (From: Internet, Google Images) 
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Figure 2. Map of Ao Manao Bay, Wing 5 Showing the RTAF Base and Airstrip 

(From: Google Earth) 


1. Equipment Tested During COASTS Experiment 


During the live experiment, there were five main data collection and transmission 
platforms that comprised the system being tested. These were: (1) the RTAF’s AU-23 
Peacemaker Monoplane; (2) the AeorVironment Raven RQ-llb Mini Unmanned Aerial 
Vehicle (MUAV); (3) the Royal Thai Navy’s (RTN) Pattani-Class Patrol Craft, Fast 
(PCF); (4) the JOCC; and (5) a Mobile Emergency Command Post (MECP) that utilized 
an experimental cell phone technology developed at NPS known as Twiddlenet. The 
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following subsections provide a brief description of each technology as well as its 
purpose during the COASTS experiment and Figure 3 provides a more detailed view of 
the experiment area to include how various equipment was connected to the JOCC. 
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Figure 3. Aerial View Showing Flow AU-23, PCF, MUAV, and MECP were 
Communicating with the JOCC (From: COASTS Network P-Point) 


a. Royal Thai Air Force’s AU-23 Monoplane (Peacemaker) 

The AU-23 Peacemaker is essentially a modified version of the Swiss 
Pilatus PC-6 Porter civilian utility aircraft. First introduced in the late 1950s, the 
currently used turboprop version was introduced in 1961 and then upgraded in 1963 to its 
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current engine configuration. Within the United States, the AU-23 was produced by 
Fairchild Industries who in turn sold 35 of the aircraft to the Royal Thai Air Force 
following Vietnam. 

The AU-23 is famous for its short take-off-and-landing (STOL) capability 
requiring little more that a soccer field to do both. Operated by a single pilot, the AU-23 
and can hold up to 10 passengers, has a maximum speed of 153 mph, a maximum range 
of 870 nautical miles and a maximum operating altitude of 25,000 ft. Since the RTAF 
variant is armed, it is used primarily for counter-insurgency operations making it a 
perfect fit for surveillance. 

During the live experiment, the AU-23 was equipped with very high 
frequency (VHF) communications as well as a video capability. It was launched 
immediately for the purpose of providing the JOCC initial reports of the disaster area to 
include route information that could be used to direct the MECP. 

b. Raven RQ-llb Mini Unmanned Aerial Vehicle 

The Raven RQ-llb or Raven B is a MUAV manufactured by 
AeroVironment, Inc. Its purpose is low altitude surveillance and reconnaissance and is 
used by militaries throughout the world. Due to the system’s mobility and rapid 
deployment capability, is currently regarded as the “most prolific unmanned aerial 
vehicle system in the world today.” 2 

The Raven B is a hand launched MUAV that can be guided by a ground 
station or fly autonomously using advanced global positioning system (GPS) navigation. 
It power plant is a battery powered electric motor giving it a limited endurance of 60 to 
110 minutes depending on battery type. 


2 Wikipedia, http://en.wikipedia.org/wiki/RQ-l 1 Raven 
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The Raven B has a line-of-site (LOS) range up to 10 kilometers, speed 
from 32-81km/h, and a maximum operating altitude of approximately 
500ft above mean ground level (MGL) or 14,000ft above mean sea level 
(MSL). The Raven can deliver real time color or infrared imagery to the 
ground control and remote viewing stations. 3 

During the live experiment, the Raven B was launched from the JOCC site 
only after the MECP had reached its destination. Once over the disaster area, the MUAV 
was used to survey the damage and provide real time color video back to the control 
station located close to the JOCC which was then routed via a wireless link to the JOCC. 

c. Royal Thai Navy’s Patrol Craft , Fast 

Powered by a diesel chassis and large enough to house a small crew, the 
PCF packs enough punch to not only patrol the calm riverine and coastal water but to also 
endure the choppy seas when required. The PCF’s relatively small size makes it a perfect 
fit for such missions as anti-smuggling, anti-trafficking, fishery enforcement, and anti¬ 
piracy. 

During the live experiment, the PCF was dispatched to the disaster area in 
order to augment the aerial assessment provided by the AU-23 and to provide a coastal 
perspective of the damage. Its primary mission was to transmit a voice report back to the 
JOCC via VFIF communications and then loiter in the area providing aid where needed. 

d. Joint Operations Command Center 

The JOCC was located on base in a pre-existing building located out of 
the disaster area but close enough to it that the aerial platforms could perform their 
mission. The JOCC was the central coordination point for the MUAV operator, MECP 
Team, and additional support personnel prior to, and during, the COASTS experiment. 
The JOCC was set-up so that all could obtain and maintain a common operational picture 
of what was occurring. It was the nerve center of the experiment and was home to all key 


3 AeroVironment website, http://www.avinc.com/uas product details. asp?Prodid=l 
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crisis team personnel. All functions of the experiment were controlled from the JOCC to 
include the commands for launch and recovery of aerial and ground platforms, audio and 
video reception/transmission, and report generation/dissemination. 


e. Mobile Emergency Command Post and Twiddlenet 

As previously mentioned, the MECP represented any ground platform that 
has the ability to safely transport a specified amount of personnel, supplies, and data 
collection equipment into the disaster area for purposes of damage assessment. For the 
purposes of this experiment, the MECP platfonn was a 10-passenger van. The MECP 
also performed emergency medical services once in place but this is a secondary mission 
to the primary of data collection. 

The key technology of the MECP is the NPS-developed Twiddlenet. The 
attraction to Twiddlenet is that it can tie cell phones and personal digital assistants (PDA) 
into a hastily formed network (HFN) created by the crisis team. This capability is 
extremely beneficial and has enonnous applicability when the disaster area has lost 
commercial cell phone communications. During the live experiment, the Twiddlenet 
operating within the MECP performed the mission of providing video and data 
transmissions back to the JOCC. 

2. Brief Summary of Live Experiment Scenario Script 

The post tsunami scenario script developed and executed by COASTS can be seen 
in its entirety in Appendix A. The following is a brief summary of the script and what 
occurred. (During the live experiment, what was supposed to happen according to the 
script and what did happen were close enough for the purposes of this project that it can 
be summed up as “what occurred.”) 

Approximately one hour after a tsunami hits the coastline, the crisis team, 
consisting of all scenario participants and equipment, is assumed to have already arrived 
near the disaster site and requests pennission from local authorities to survey the affected 
area. Once pennission to survey the disaster area is given, the simulation clock begins. 

Approximately one hour of coordination and preparation takes place and it is at the 
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conclusion of this hour that the equipment is ready to be employed. The Hastily Formed 
Network (HFN) used to tie all crisis team equipment together is also established as part 
of the JOCC preparation during the one-hour coordination and equipment preparation 
window allowing the system to operate independent of local communications 
infrastructure. The timeline below represents simulation time, not real clock time during 
the live simulation: 

• 0:00 to +1:01 the equipment is prepped, coordination takes place, and the 
HFN is established 

• +1:02 the AU-23 Monoplane takes off for purposes of surveying the 
disaster area 

• +1:03 the MECP departs the base enroute to the affected area for purposes 
of damage assessment and triage 

• +1:15 the AU-23 arrives over disaster area and starts streaming video 
back to JOCC via very high frequency (VHF) communications 

• +1:15 the RTN patrol boat arrives in the disaster area and provides a 
damage assessment using Voice Over Internet Protocol (VOIP), remains 
in area until end of scenario 

(Timeline Compression) 60 minutes simulated elapsed. At this point in the 
script, there is a 60-minute timeline compression thereby adding one hour to the 
simulation timeline. During this simulated hour, routes are determined into the disaster 
area for disaster relief teams. The JOCC relays this information to the MECP Team who 
was already on the move to the disaster area and the AU-23 uses loiter capability to 
remain over the disaster area and provide continued support until end of scenario. 

• +2:20 MECP arrives at disaster site and begins setting up links, MUAV 
launched from base to support MECP 

• +2:40 MECP setup complete, data transfer with JOCC ongoing via 
satellite communications (SATCOM), MUAV providing JOCC with video 
feed of disaster area 
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• +2:45 JOCC sends disaster reports to host-nation command center and 

local non-governmental organization (NGO) headquarters 

3. Brief Summary of Live Experiment Results 4 

a. Pre-Experiment Test Runs 

The final COASTS experiment was preceded by a handful of practice 
experiments, or test runs. There were a number of hang-ups just prior to and during 
these practice experiments such as a power outage at the JOCC. Since the JOCC is the 
hub for all communications as well as the centerpiece for the HFN, losing power became 
a critical situation. Every activity in the system was eventually affected by the power 
outage and having a backup power source became a key learning point. In addition to the 
JOCC power outage, a severe rainstorm popped up during one of the test runs bringing 
with it high winds, heavy rain, and lightning. The storm wreaked havoc on the system as 
a whole resulting in the grounding of all aircraft and damages to the MUAV and HFN 
infrastructure. These particular occurrences in addition to a few more potential issues are 
used in experimental scenario development contained in Chapter IV. 

b. Live Experiment 

During the full live experiment run the HFN proved to be reliable and 
favorable weather conditions allowed the AU-23 and MUAV to get in the air, loiter over 
the disaster area, and transmit data back to the JOCC for use elsewhere in the scenario. 
The MECP kept to the timeline and was able to accomplish all tasks including image 
transmission and the delivery of emergency medical services to the victims within its 
immediate area. By all accounts the live experiment was a success and the data 
collection system proved to be capable of operating under favorable conditions. 


4 Summary taken from FEX V Daily Sitrep (Final) from Tuesday, May 27, 2008 (Appendix B) 
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III. SCRIPT AND BASELINE MODEL 


Chapter III begins with assumptions and key metrics for all models developed as 
part of this project. Next, the construction of the Script and Baseline Models is described 
to include details about the commonalities of the models such as flow, activities, and 
outlines what is contained in each. Finally, the Script and Baseline models are compared 
using the metrics defined below. 

A. ASSUMPTIONS 

The overarching objective of this project is to expand on the live experiment in 
order to test the performance of the entire system under a variety of circumstances, not to 
test the individual equipment, technologies, and preparation that made it possible. 
Therefore, assumptions are necessary. The first two models constructed for this project 
were the Script Model that contains no variability but matches the live simulation script 
and a Baseline Model where probability distributions were inserted for timed activities to 
reflect real world variability. The Baseline Model also serves as the model from which 
the experimental models were created. The following is a list of assumptions which apply 
to all models: 

• The disaster area is within range of all equipment 

• The weather conditions ultimately permit the systems employment, 
although may cause delays 

• All equipment and personnel are ultimately functional although may 
experience recoverable failures 

B. METRICS 

In keeping with the main purpose of this project, which is to expand on the 
COASTS experiment and explain how the data collection system would operate under 
more realistic conditions, a metric of total time to mission completion is used to evaluate 
and compare all models. For the purposes of this project, total time means the time it 
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takes for the JOCC to generate and transmit a comprehensive damage assessment to the 
non-governmental organizations (NGOs) supporting the DR/HA effort. This step is what 
all other activities in the system are working towards, the step that will take all compiled 
data and turn it into usable information. Until this happens, it is assumed that the only 
persons who know the full extent of the damage are the victims and the HA/DR 
personnel on site working to produce the assessment. 

That said, there are additional metrics that can be useful, such as the time it takes 
for each entity to survey the disaster area and transmit a damage assessment to the JOCC. 
These metrics can be extremely helpful when examining the effects of temporary failures 
and weather delays in the enhanced models, further demonstrating how problems with 
one entity can significantly delay all others. 

C. SCRIPT MODEL 

The Script Model was built according to the COASTS script with all times 
constant. The model times are simulation times as opposed to real times and are based on 
an interpretation of the script which lasts 165 minutes. What was not built into the Script 
Model was the time it takes for the crisis team to travel to the disaster area, link up with 
the host nation (HN) government, and gain permission to setup and employ the system. 
This cannot be projected due to the global nature of disasters, various modes of travel, 
requirements of and relationships with different governments, and a whole host of other 
variables beyond the control of all involved. 

1. Script Model Flow 

The simulation model was developed by first creating a precedence diagram for 
all the activities involved in the mission. As described later, the Script and Baseline 
Models have exactly the same flow. The only difference between them is the activity 
times which are constant in the Script Model and probabilistically distributed in the 
Baseline Model. Subsequent paragraphs will provide a description of the model flow as 
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well as flowchart snapshots (Figures 4&5). The following precedence table (Table 1) 
was compiled to construct the model flow and the activity letters in the table correspond 
to the activity letters in the flowchart figures. 


ACTIVITY PRECENDENCE TABLE 

ACTIVITY DEFINED 

ACTIVITY 

PRECEEDS 

PREP AU-23 

A 

F 

PREP JOCC 

B 

C 

PREP PCF 

C 

G 

PREP MECP 

D 

H 

PREP MUAV 

E 

I 

AU-23 LAUNCH AND TRANSIT TO DISASTER AREA 

F 

J 

PCF LAUNCH AND TRANSIT TO DISASTER AREA 

G 

K 

LAUNCH MECP AND BEGIN TRANSIT TO DISASTER 

AREA 

H 

M 

MUAV LAUNCH AND TRANSIT TO DISASTER AREA 

I 

0 

AU-23 SURVEYS DISASTER AREA AND SENDS DATA 

TO JOCC 

J 

L 

PCF SURVEYS DISASTER AREA AND SENDS DATA TO 

JOCC 

K 

L 

JOCC PROCESSES DATA FROM AU-23 AND PCF, SENDS 
ROUTE DATA TO MECP 

L 

M 

MECP RECEIVES ROUTE DATA FROM JOCC 

M 

N 

MECP TRANSITS TO DISASTER AREA 

N 

1,0 

MECP SETS UP, SURVEYS, AND SENDS DATA TO JOCC 

0 

0 

MUAV SURVEYS DISASTER AREA AND SENDS DATA 

TO JOCC 

P 

Q 

JOCC PROCESSES DATA FROM MECP AND MUAV, 
SENDS DAMAGE ASSESSMENT TO NGO’S 

Q 

END 


Table 1. Activity precedence table for use with model flowchart (Figures 4 & 5) 


The activity flow in the model commences with the Tsunami strike which leads to 
the crisis team link-up with local government officials (both civil and military). Once the 
link-up takes place and authorization is given to the COASTS team to survey the disaster 
area, a preparation phase starts that includes the crisis team establishing the HFN and 
prepping all equipment. The AU-23 is launched first for the purpose of providing initial 
damage assessments and to report back with usable route information that can be passed 
from the JOCC to the MECP. As the AU-23 launched, the MECP is dispatched to the 
disaster area with the intention of receiving route updates on the move in order to find its 
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intended destination. Also at the same time, the PCF is directed to proceed from a nearby 
port to the shoreline of the disaster area in order to provide reports based on the coastline 
perspective. After a short transit time, the AU-23 arrives at the disaster area and begins 
transmitting video and damage assessments back the JOCC. Similarly, after some transit 
time, the PCF arrives at the disaster area and communicates damage assessment 
information to JOCC. The JOCC uses all this information to generate route information 
that can be passed along to the MECP (Figure 4). 


AU-23 LAUNCH AND AU-235URVEY5 DISASTER 
TRANSmO DISASTER AREA AND SENDS DATA TO 

PREP AU-23 arfa inrr 



Figure 4. Flowchart Snapshot Showing Tsunami Strike, Preparation Processes, and 

Data Transmissions To and From JOCC 


Upon the MECP’s arrival at its final destination, the signal is given for the 
MUAV to launch. The MECP then proceeds to set up and the MUAV is directed over 
the disaster area by the JOCC in order to survey the affected area and transmit assessment 
data back to the JOCC. The MECP is now set up, the MUAV is over the disaster area, 


18 










and both are transmitting video and data back to the JOCC. The JOCC uses information 
from the AU-23, PCF, MUAV, and the MECP to complete the final system step of 
transmitting the summarized damage assessment report to the NGO’s (Figure 5). 


JOCC PROCESSES DATA 
FROM MECP AND UAV. 
SENDS REPORTTO NGO S 


FROM L 



MUAV LAUNCH AND 
TRANS mo 
DISASTER AREA 


MUAV SENDS 
DATA TO JOCC 



Figure 5. Flowchart Snapshot Showing JOCC’s Transmission to NGO’s 


2. Script Model Creation 

The Script Model was created with processes for the activities defined above and 
flows that follow the description given above. Details about the entities and the processes 
within the Script Model are described below. As previously noted, the Script Model was 
based solely on the COASTS Tsunami scenario script and contains no variation, meaning 
all process times are constant. 

a. Entities 

The description and role of each equipment entity have been previously 
explained in Chapter II. Additional entities, denoted PTP, represent communications 
between other entities. Table 2 builds on the existing entity information by showing what 
resources are required for each equipment entity to carry out any process activities. The 
resources are assigned a representative letter in Table 3 that is referred to in Table 4. 
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Entity 

Associated Resource 

1 

AU-23 

(a) Air Crew; (b) Pilot 

2 

PCF 

(c) PCF Crew 

3 

Mini Unmanned Aerial Vehicle 

(d) MUAV Pilot 

4 

PTp 


5 

MECP 

(e) MECP Crew; (f) MECP Security Team 

6 

JOCC 

(g) JOCC Team 


Table 2. Entity infonnation for script model 


b. Processes 

For processes, all Type were standard, all Actions were seize-delay- 
release, all Priority were the same (medium 2), Allocation was set to value added for 
each, and all Units are in minutes. The table below denotes the constant process delay 
times and the resources required for each process. 
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a=Air Crew b=Pilot c=PCF Crew d=MUAV Pilot e=MECP Crew f=MECP Security Team 

g=JOCC Team 


Process 

Resource(s) 

Minutes 

1 

PREP AU-23 

a, b 

62 

2 

PREP JOCC 

g 

60 

3 

PREP PCF 

c 

60 

4 

PREP MECP 

e, f 

63 

5 

PREP MUAV 

d 

139 

6 

AU-23 LAUNCH AND TRANSIT TO DISASTER AREA 

b 

8 

7 

PCF LAUNCH AND TRANSIT TO DISASTER AREA 

c 

10 

8 

LAUNCH MECP AND BEGIN TRANSIT TO DISASTER 

AREA 

e, f 

17 

9 

MUAV LAUNCH AND TRANSIT TO DISASTER AREA 

d 

15 

10 

AU-23 SURVEYS DISASTER AREA AND SENDS 
DATA TO JOCC 

a 

5 

11 

PCF SURVEYS DISASTER AREA AND SENDS DATA 
TO JOCC 

c 

5 

12 

JOCC PROCESSES DATA FROM AU-23 AND PCF, 
SENDS ROUTE DATA TO MECP 

g 

5 

13 

MECP RECEIVES ROUTE DATA FROM JOCC 

e, f 

5 

14 

MECP TRANSITS TO DISASTER AREA 

e, f 

55 

15 

MECP SETS UP, SURVEYS, AND SENDS DATA TO 

JOCC 

e,f 

20 

16 

MUAV SURVEYS DISASTER AREA AND SENDS 
DATA TO JOCC 

d 

5 

17 

JOCC PROCESSES DATA FROM MECP AND MUAV, 
SENDS DAMAGE ASSESSMENT TO NGO’S 

g 

5 


Table 3. Script Model processes information 


D. BASELINE MODEL 

The Baseline Model was structured on the COASTS Tsunami scenario script but 
has been injected with realistic variability by altering all process delay times to a 
probabilistic delay using a Triangular distribution. Since there was no real data 
available, it is not known what probability distribution and distribution parameters were 
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most accurate. Therefore, using one of three distributions (. Exponential, Triangular, and 
Uniform) recommended in the Arena book, the Triangular distribution was chosen since 
it is the best represents the distribution of process times for this particular project (Kelton 
pg. 183-185). This distribution calls for Minimum, Most Likely, and Maximum time 
parameters. All time parameters for the Baseline Model processes delays have been 
determined by the following methods: 

• Information and experiences gained from being present at the live 
COASTS experiment 

• Knowledge gleaned from interacting with the equipment operators 

• Answers provided by experiment attendees on questionnaire (Appendix B) 

• Ability to make inferences after 19.5 years in service 

The following table relates to the Baseline Model and only provides details about 
the processes and their changes as all other model infonnation is the same as the Script 
Model. A full view of the Baseline Model as it appears in Arena can be seen in 
Appendix D. 
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a=Air Crew b=Pilot c=PCF Crew d=MUAV Pilot e=MECP Crew f=MECP Security Team 

g=JOCC Team 


Process 

Resource(s) 

Minutes 

1 

PREP AU-23 

a, b 

30,60,90 

2 

PREP JOCC 

g 

30,90,180 

3 

PREP PCF 

c 

30,60,120 

4 

PREP MECP 

e, f 

30,90,180 

5 

PREP MUAV 

d 

10,60,90 

6 

AU-23 LAUNCH AND TRANSIT TO DISASTER AREA 

b 

10,30,60 

7 

PCF LAUNCH AND TRANSIT TO DISASTER AREA 

c 

20,60,120 

8 

LAUNCH MECP AND BEGIN TRANSIT TO DISASTER 

AREA 

e, f 

10,30,60 

9 

MUAV LAUNCH AND TRANSIT TO DISASTER AREA 

d 

15,30,45 

10 

AU-23 SURVEYS DISASTER AREA AND SENDS 
DATA TO JOCC 

a 

10,15,30 

11 

PCF SURVEYS DISASTER AREA AND SENDS DATA 
TO JOCC 

c 

15,30,60 

12 

JOCC PROCESSES DATA FROM AU-23 AND PCF, 
SENDS ROUTE DATA TO MECP 

g 

5,30,60 

13 

MECP RECEIVES ROUTE DATA FROM JOCC 

e, f 

1,5,15 

14 

MECP TRANSITS TO DISASTER AREA 

e, f 

30,60,120 

15 

MECP SETS UP, SURVEYS, AND SENDS DATA TO 

JOCC 

e, f 

30,60,180 

16 

MUAV SURVEYS DISASTER AREA AND SENDS 
DATA TO JOCC 

d 

5,10,30 

17 

JOCC PROCESSES DATA FROM MECP AND MUAV, 
SENDS DAMAGE ASSESSMENT TO NGO’S 

g 

20,40,90 


Table 4. Baseline Model processes infonnation 


E. SCRIPT AND BASELINE MODEL RESULTS AND ANALYSIS 

The Script Model results did not deviate from the COASTS Experiment scenario 
that was executed. This model was that way to provide a benchmark that could be built 
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upon, and also so that enhancements could be added. The results generated by the Script 
Model (Table 5) follow the script event flow perfectly showing that it took ultimately 165 
minutes for the JOCC to send the damage assessment to the NGO’s. 

Table 5 highlights the difference in times needed to send data from one entity to 
the next starting at simulation time zero and ending at the time the communications 
happened. These metrics are our best gauge of how the system functions and can quickly 
reveal possible problems. The Baseline Model has been replicated 200 times. This 
number of replications was chosen because it is a large enough sample to produce 
acceptable Average times based on the Confidence Interval (value range above and below 
the average based on the half width) also displayed in Table 5. All Times in Table 5 have 
been rounded to the nearest minute. 


**A11 Time is in 

Script Model 

K Baseline Model 



Minutes 

(Constant 

Delay) 

| (Triangular Delay, 200 Replications) 



Time Until 

Data Sent 

Average Time 
Until Data Sent 

Confidence 

Interval 

Min 

Max 

AU23 to JOCC 

75 

111 

[109, 114] 

71 

154 

PCF to JOCC 

75 

173 

[169, 177] 

97 

238 

JOCC to MECP 

80 

205 

[201,210] 

136 

287 

MUAV to JOCC 

160 

327 

[322,331] 

225 

422 

MECP to JOCC 

160 

372 

[365, 378] 

233 

497 

JOCC to NGO 

165 

423 

[416, 430] 

293 

558 


Table 5. Comparison of Script and Baseline Model metrics 


The value of the Baseline Model is that it provides a more realistic picture of the 
system by using a range of possible process times as opposed to assigning a specific 
value to the processes or shortening them for the sake of the experiment as with the Script 
Model. Therefore the Baseline Model is the starting point for all experimental models 
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described in Chapter IV. As expected, the Baseline Model, having been injected with 
more realistic process times and process time variability, shows that it takes 
approximately 128 minutes longer to get the damage assessment from the JOCC to the 
NGO’s best case, 423 minutes longer worst case, and 258 minutes longer on average. In 
essence, based on the simulation results, it takes, on average, seven hours for the damage 
assessment system to realistically run its course given the parameters listed in Table 4. 
As previously stated in this chapter, due to time and resource constraints, some of the 
script activities were not fully acted out during the COASTS experiment which would 
account for the large time differences in Table 5. 
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IV. EXPERIMENTAL MODELS 


Once the Baseline Model has been established, the model can be further expanded 
to include the possibilities of other random events such as equipment failures and bad 
weather delays. Chapter IV provides details on about the creation of three experimental 
models that were designed using the Baseline Model as the starting point. 

A. EQUIPMENT FAILURE MODEL 

Equipment failures are inevitable and inherent part of any system and must be 
planned for. Failures of this nature are generally random and can be reduced by 
aggressive preparation, planning and preventative maintenance. However, the possibility 
of equipment failures can never be eliminated. That said, in order to test this system 
under more realistic conditions, this model enhancement must be included. The model 
demonstrates how equipment failures that have been assigned probabilities and triangular 
delay times can impact the amount of time is takes for reports to be sent across all paths. 

Using the Baseline Model as a start point, temporary failure delays were built into 
the model by first creating a Failure Table within the modeling software using the data in 
Table 6. Specific data for failure likelihoods were not available due to the fact the 
COASTS experiment summary did not incorporate failure data; therefore, Probabilities 
and Down Times in Table 6 are reasonable guesses. 

The equipment and problems listed in Table 6 were reasonable estimations based 
on a combination of factors such as age of equipment, projected reliability of power grid 
following a disaster and most likely issues based on equipment type. The probabilities 
and down time associated with these problems were determined much the same way and 
are a mix of reasonable guesses based partially on real issues that surfaced during the dry 
runs mentioned at the end of Chapter I. 
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Equipment 

Problem 

Probability of Problem 
Occurring 

Time Down 
in Minutes 

AU-23 

Gauge Malfunction 

5% 

1, 15, 60 

JOCC 

Power Outage 

1% 

1,30, 120 

MECP 

Mechanical Problems 

5% 

5, 30, 60 

MUAV 

Battery Not Charged 

3% 

30, 60, 90 

PCF 

Engine Will Not Start 

5% 

5, 15, 60 


Table 6. Details of failures built into Baseline Model to create Equipment Failure Model 


When creating the Failure Table, the failure Type for all was time and the formula 
used to populate the Up Time field was based on a discrete probability using the 
expression: DISC (probability of problem, UNIF (0, mimimum system run time from 
Baseline Model), 1.0, 10000). For example, the formula for AU-23 Up Time is DISC 
(0.05, UNIF (0,293), 1.0, 10000). This formulation for Up Time allows the coding of a 
probability that the failure will occur during the simulation run. To insure that, if failure 
was supposed to happen according to the results of the draw from the discrete 
distribution, that the failure did actually occur, the longest possible Up Time for this case 
was set to 293 minutes, which was determined from the Base Model results to be the 
fastest time that the simulation could run. Note however, that it is possible for an 
equipment failure to occur after that equipment has sent its required communication so 
the failure may not necessarily cause the delay of other activities. This was determined to 
be the most realistic and effective way to code the failures. 

The Down Time field was populated using a triangular distribution using the 

numbers presented in Table 6. Once the failures were created they were associated to the 

equipment via resources needed to operate the equipment. For example, the Pilot is a 

resource needed to operate the AU-23 throughout every process; therefore by attaching 

the failure probability to the pilot, the AU-23 is by probabilistically failed by association. 

This association to a resource other than the actual equipment was required since the 

equipment was modeled as an entity rather than a resource. This strategy required a 
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slight modification to the Baseline Model when it came to the JOCC Power Outage 
failure. Since a power failure affects ah data transmission to and from the JOCC, ah data 
transmission activities had to be isolated in their own processes so ah necessary resources 
could be properly required, and therefore ah data transmissions properly affected by a 
failure. Therefore ah processes that combined surveying and data transmission had to be 
split. This allowed for the JOCC Team resource, with the power failure attached to it, to 
be added to ah data transmission processes, regardless of which piece of equipment was 
communicating with the JOCC. The newly added Send Data processes for each piece of 
equipment were given a constant time of 1 minute. Consequently, ah process times 
associated with the Survey process were reduced by 1 minute as to not skew the total time 
required for the Surx’ey and Send Data processes together. By doing this, the model 
simulated the failure of ah data transmissions, regardless of which equipment failed, 
injecting additional realism into the model. 

B. WEATHER DELAY MODEL 

As with equipment failures, bad weather is also something relief workers have to 
consider. For the purposes of this project, bad weather is defined as heavy rain, flooding, 
high seas, or high winds, or something of the like which exists to some degree during the 
disaster response window. The residual effects of weather related disasters such as 
hurricanes and typhoons are likely factors that will impact the response and must be 
planned for. The Weather Delay Model is designed to simulate likely delays due to bad 
weather. 

The Weather Delay model used the Baseline Model as a starting point just as the 
Equipment Failure Model did. Temporary delays were built into the model by creating a 
Weather entity. The Weather entity was then sent into a decision module that was given 
the probability of 10%, Every time this decision is true, the Weather entity proceeds to 
an assign module where it changes the value of a variable named Bad Weather from the 
initial value of zero to a new value of 1 (Figure 7). 
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Figure 6. Snapshot of Arena 10.0 Module Additions Needed to Complete the 

Weather Delay Model 

The variable Bad Weather has been li nk ed to each process that would be delayed 
(Table 8) using a mathematical expression inserted in the Delay Type field of each 
affected process module. The expression, TRIA( , , ) + Bad Weather * TRIA( , , is 
designed to use the original process times (Table 4) in the first set of parenthesis and the 
estimated additional delay times due to bad weather (Table 8) in the second set of 
parenthesis. When the Bad Weather variable retains its default value of zero, the 
additional process delay time is cancelled out so only the original process delay is 
experienced. Just like the Equipment Failure Model, specific data for delay likelihoods 
were not available due to the fact the COASTS experiment summary did not incorporate 
weather delay data; therefore, the processes that would be delayed and the additional 
weather delay times in Table 7 are reasonable guesses based on a mixture of reasonable 
guesses and real issues that surfaced during the dry runs mentioned at the end of Chapter 
I. 
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Process Being Delayed 

Additional Delay 

in Minutes 

PREP JOCC 

5,30, 90 

PREP PCF 

10, 30, 60 

AU-23 LAUNCH AND TRANSIT TO DISASTER AREA 

20, 45, 90 

PCF LAUNCH AND TRANSIT TO DISASTER AREA 

20, 40, 60 

LAUNCH MECP AND BEGIN TRANSIT TO DISASTER AREA 

5,30, 90 

MUAV LAUNCH AND TRANSIT TO DISASTER AREA 

10, 20, 45 

AU-23 SURVEYS DISASTER AREA AND SENDS DATA TO JOCC 

5, 10, 15 

PCF SURVEYS DISASTER AREA AND SENDS DATA TO JOCC 

10, 30, 60 

MECP TRANSITS TO DISASTER AREA 

10, 20, 60 

MECP SETS UP, SURVEYS, AND SENDS DATA TO JOCC 

15,45, 120 

MUAV SURVEYS DISASTER AREA AND SENDS DATA TO JOCC 

1, 5, 10 


Table 7. Processes affected by bad weather with associated delay times 


C. COMBINATION MODEL 

The Combination Model combines the two previous experiments and is designed 
to simulate likely delays due to equipment failures and bad weather. It is the Baseline 
Model with all of the equipment failures and weather delays of the previous two models 
added in. Since the Equipment Failure Model split the four Survey and Send Data 
processes into eight processes, the Bad Weather Delay that was originally associated with 
those processes was applied to the Survey portion and not the Send Data. The results and 
analysis of all models are presented in Chapter V. 
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V. RESULTS AND ANALYSIS 


The following paragraphs and tables provide summarized results and analysis of 
all models with variability. More specifically, the goal of this chapter is to show the 
averages and the ranges and variation when comparing the three experimental models to 
the Baseline Model, emphasizing the differences between the Average, Minimum, and 
Maximum time needed to send data. As previously stated, each model has been 
replicated 200 times. 

A. RESULTS AND ANALYSIS OF AVERAGE TIMES 

Table 8 shows Average Time Until Data Sent. To understand the results in Tables 
8, 9, and 10, a rough critical path analysis was performed based on most likely process 
delay times. The critical path for this system, defined as path that goes from start to 
completion which takes the longest, is: Process C-G-K-L-M-N-O-Q. The critical 
path takes a total of 335 minutes using Most Likely times from Table 4 and is linked at 
some point to all other paths. All other paths have significantly lower Most Likely times, 
and therefore have quite a bit of slack. 

The Equipment Failure Model average times reflected in Table 8 do not vary 

much from the Baseline Model averages. There is one significant jump in the AU23 to 

JOCC path of 10 minutes but the remaining communications only took one to two 

minutes longer. When considering the confidence intervals in Table 9, this difference is 

not significant. Looking back at Table 6 (details of Equipment Failure Model) it would 

seem as though there would be a larger time difference in the other five paths. However, 

this small change is due to a complex set of factors that includes number of replications, 

probabilities of equipment failure delays, slack time in others paths when compared to the 

critical path, and the larger difference between the Most Likely and Maximum times in 

the Triangular delay. For instance, when looking at the AU-23 to JOCC path which had 

the largest increase in time, there are three processes in that path that could experience an 

equipment failure. Each of those occurrences has a 5% probability. This specific path is 

not the critical path; it does not take nearly as long as the critical path, and has relatively 
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low delay times. Therefore, though changes occur in leaps on this path they do not 
necessarily affect the other five paths due to lack of influence on one another or due to 
the path being connected to takes considerably longer anyway and is not impacted by 
changes on the shorter path. 



Average Time Until Data Sent For All Models (200 Reps) 


Script 

Baseline 

Eqpmt Failure 

Bad Weather 

Combination 

AU23 to JOCC 

75 

111 

121 

116 

127 

PCF to JOCC 

75 

173 

174 

180 

183 

JOCC to MECP 

80 

205 

205 

213 

216 

MUAV to JOCC 

160 

327 

329 

342 

346 

MECP to JOCC 

160 

372 

374 

392 

390 

JOCC to NGO 

165 

423 

424 

444 

443 


Table 8. Comparison of average times until data sent for all models 



95% Confidence Intervals (based on 200 Reps) 


Baseline 

Eqpmt Failure 

Bad Weather 

Combination 

AU23 to JOCC 

[109, 114] 

[118, 124] 

[113, 120] 

[122, 130] 

PCF to JOCC 

[169, 177] 

[170, 178] 

[175, 184] 

[178, 189] 

JOCC to MECP 

[201,210] 

[202, 209] 

[209,218] 

[209, 220] 

MUAV to JOCC 

[322,331] 

[324, 334] 

[335, 349] 

[338, 354] 

MECP to JOCC 

[365, 378] 

[368,381] 

[383,401] 

[381,399] 

JOCC to NGO 

[416, 430] 

[418,431] 

[435, 453] 

[433,453] 


Table 9. 95% Confidence Intervals 
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The Weather Delay Model on the other hand varied quite distinctly from the 
Baseline and Equipment Failure Models with significant increases in five out of six 
average time metrics. These increases can be attributed to the same complex 
combination of factors mentioned above but it is the details of these factors that help 
explain the larger increases. The greatest impact on average times is the fact that the 
Weather Delay Model carries a higher probability of 10% as opposed to the Equipment 
Delay Models range of 1% to 5%. Additionally, the Weather Delay Model also contains 
a wider variation of delay times when compared to the Equipment Failure Model, which 
could account for the AU-23 to JOCC average time being smaller when compared to the 
Equipment Failure Model. 

Finally, the Combination Model was expected to show an increase in average 
times beyond that of the Equipment Failure and Weather Delay Models, especially in the 
JOCC to NGO path (which is on the critical path). The expectation to see a significant 
increase was due to the fact that the delays would build on each other in turn resulting in 
higher averages when compared to all other models. This did occur in four out of six 
communication paths and with reasonable accuracy, as you would expect the 
Combination Model average times to roughly equal the difference in the Equipment 
Delay Model and Baseline Average Times added to the Weather Delay Model average 
times. Of the two paths that did not increase, there was one path that in particular that 
was extremely difficult to comprehend, the JOCC to NGO path which apparently 
decreased by one minute. Due to this unexpected result, the experimental models were 
re-examined to insure there were no model errors, and re-run for 1,000 replications but 
the results showed little variation with the exception of a reduction in half width. Despite 
the fact the half-widths were reduced, the confidence intervals continued to overlap and 
more closely than those shown in Table 9 leading to the conclusion are not significantly 
different. It is reasonable to conclude that running the models for 5, 10, or 15 thousand 
replications would further hone in on the true average times but for a system that takes 
400+ minutes to complete the mission, detennining if one model actually takes half a 
minute more than another on average is not significant enough to warrant this more 
extensive analysis. However, it is somewhat surprising that the addition of equipment 
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delays (the only difference between the Baseline Model and the Equipment Failure 
Model, as well as between the Weather Model and the Combined Model) is not slightly 
more noticeable. 

B. RESULTS AND ANALYSIS OF MIN AND MAX TIMES 

Greater variation is expected when comparing the min and max metrics due to the 
likelihood of outliers. Tables 10 and 11 show minimum and maximum time results for 
all models respectively based on 200 simulation replications. These metrics would likely 
act as a guide for relief workers showing them the earliest and latest likely times they 
could plan to execute follow on activities. Just like in the average times comparison 
table, the resulting times in these tables reflect more of the same phenomenon with regard 
to unexpected results. 



Minimum Time Until Data Sent For All Models (min) 


Script 

Baseline 

Eqpmt Failure 

Bad Weather 

Combination 

AU23 to JOCC 

75 

71 

81 

69 

79 

PCF to JOCC 

75 

97 

107 

112 

114 

JOCC to MECP 

80 

136 

143 

144 

139 

MUAV to JOCC 

160 

225 

251 

249 

255 

MECP to JOCC 

160 

233 

270 

274 

277 

JOCC to NGO 

165 

293 

312 

337 

315 


Table 10. Comparison of minimum times until data sent for all models 
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Maximum Time Until Data Sent For All Models (min) 



Script 

Baseline 

Eqpmt Failure 

Bad Weather 

Combination 

AU23 to JOCC 

75 

154 

173 

200 

233 

PCF to JOCC 

75 

238 

275 

299 

299 

JOCC to MECP 

80 

287 

312 

346 

331 

MUAV to JOCC 

160 

422 

472 

558 

552 

MECP to JOCC 

160 

497 

508 

607 

626 

JOCC to NGO 

165 

558 

554 

670 

668 








Table 11. Comparison of maximum times until data sent for all models 


When comparing the Equipment Failure Model to the Baseline Model for both 
min and max, we see that there is an increase in times across the board with the exception 
of the max time for the JOCC to NGO path. This can only be explained in much the 
same way as the average time phenomenon for the same path above. Since this 
communication is on the critical path and there is considerable slack on those paths 
around it, fluctuations in those paths do not affect JOCC to NGO path, in this case 
causing it to actually decrease by 2 minute. That said, all previously mentioned factors 
such as probabilities of failure and delay combined with variable delay times cannot be 
overlooked and surely contribute to this unexpected result. 

The remaining models show much of the same unexpected pattern when 
compared to the model that precedes it. Both min and max times would be expected to 
increase when going from the Baseline Model to the Combination Model respectively but 
as shown Tables 10 and 11 are littered with data points which prove otherwise. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 


As previously stated, the COASTS Experiment proved that the damage 
assessment system tested in this project works and is a realistic option when looking for a 
system that can provide support in a disaster situation. This project expands on their 
experiment by using discrete event simulation to determine realistic times for setting up 
and employing this system. The following discussion provides a wrap up of the project 
to include conclusions based on model results and recommendations on project 
improvement and continued research. 

This project used the COASTS Experiment as a starting point for a more detailed 
and realistic study of a specific damage assessment system. A highlight of this project is 
the difference between the Script Model when compared to the other four models. The 
considerable difference in average times supports the points made in Chapter I regarding 
live experiment limitations and the value of DES modeling. 

As with any type of research, there are a number of issues that surfaced 
throughout the study, which provided insight for areas of improvement. The most 
significant recommendation towards the improvement of this project would be the 
collection of real data points for use in the models. Despite the fact that the COASTS 
Experiment was based on a script and that data points used in the simulation model were 
relatively good estimates based on real experiences, the documenting of real prep times, 
set up times, flight times, failure times, etc., would provided an even more realistic 
foundation for these DES models. That said, recording a comprehensive list of data 
points would have not been reasonable due to the time compression and constraints of the 
COASTS Experiment, but consideration should be given to conducting future live 
experiments that involve all activities being acted out from beginning to end. In addition 
to data points associated with time, recording the effect that severe weather has on the 
equipment being tested is recommended. 
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With regard to future research in this area, I would recommend the continued 
study of damage assessment systems similar to or with the same purpose as the one in 
this project. In my opinion, although there has been a tremendous amount of research 
conducted in each subsystem to include HFN’s and MUAV’s seemingly, little attention 
has been given to putting these subsystems together in the fonn of a multi-pronged 
assessment system capable of providing so much critical information and communication 
abilities for so many disaster response participants. 
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APPENDIX A (SCENARIO SCRIPT) 


Humanitarian Assistance Phase-1 Scenario Script 

00:00 Phase 1 COMEX. One hour after the tsunami has hit the coastal 
region. The CTF-COASTS liaison to COASTS team requests assistance to 
survey the scope of the disaster and initiate search, rescue, and recovery 
efforts. After an additional hour of coordination and crisis planning, 
COASTS has determined how best to support this request and coordinate the 
support with the host-nation. Time elapsed since Tsunami +02:00. 

00:01 JOCC Directs AU-23 Mosquito to be launched from Wing-5 and 
dispatched to disaster region. 

00:01 JOCC Director (Ch-1): “Airboss, JOCC, launch alert AU-23 to disaster 
region.” 

Airboss (Ch-1): “Roger, launch alert AU-23” 

00:01+30 Airboss (VHF): “Mosquito 01, Airboss, launch and depart to disaster area, 
report on ground routes and extent of damage” 

Mosquito 01 (VHF): “Roger, launch and depart” 

00:02 Mosquito 01 (VHF-tower): “Ao Manao Tower, Mosquito 01 ready for 
takeoff, turnout to northwest and departure to south.” 

Tower (VHF): Provides necessary clearance. 

00:02 JOCC Directs Mobile Emergency Command Post (MECP) Team 
to depart Wing-5 for disaster zone. 

00:02 JOCC Director (Ch-1): “MECP, JOCC, depart for disaster zone” 

MECP (Ch-1): “Roger, departing” 

00:03 JOCC Director (VOIP): “PCF, JOCC, transit to offshore of disaster region” 
PCF (VOIP): “Roger, departing” 

00:15 AU-23 arrives over disaster area, video provided to COASTS 

JOCC and to remote sites via COASTS network. PCF arrives in disaster 
area. 

00:15 Mosquito 01 (VHF): “JOCC, Mosquito 01, I am over disaster zone now. 

Coastal zone has sustained significant damage. Buildings and coastal road 
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appear damaged. Large number of bodies near shoreline or in water. Will 
transmit video.” 

JOCC Director (VHF): “Mosquito 01, JOCC, understand significant 
damage and loss of life, waiting on video” 

00:15+30 PCF (VOIP): “JOCC, PCF, I am offshore from disaster zone. I confirm 
report, significant damage and bodies awash in water.” 

JOCC Director (VOIP): “PCF, JOCC, tha nk you for confirmation” 

00:20 Timeline compression. 60 minutes simulated elapsed. After short 
survey of disaster area, routes are determined into the area for disaster relief 
teams. JOCC relays this information to the inbound MECP Team. AU-23 
uses loiter capability to remain over area and provide continued SA and 
support. MECP arrives in disaster area. 

00:20 MECP (SATCOM): “JOCC, MECP, we have arrived in disaster zone, 
initiating setup, standby for video, TwiddleNet, and reporting” 

JOCC Director (SATCOM): “Roger MECP, JOCC standing by” 

JOCC Director (Ch-1): “Lauch UAV” 

UAV Site (Ch-1): “Roger JOCC, launching UAV” 

00:40 MECP set up complete (including TwiddleNet) and initial reports 
data-linked back via satellite to COASTS JOCC. Mini-UAV supports 
MECP, reporting on damage to surrounding area through aerial surveillance. 

00:40 MECP (SATCOM): “JOCC, MECP, you should be receiving video and 
TwiddleNet. Coastal region has suffered significant loss of life and damage, 
this is a major disaster zone. Inland road structure is intact, but refugees are 
flooding the network. Local communications are down. Medical assistance 
and housing needs have priority.” 

JOCC Director (SATCOM): “MECP, JOCC, Roger, will pass your 
information to higher, continue observation and reporting” 

00:45 Reports on damage/scope of disaster relayed from COASTS 
JOCC to host-nation Command Center and local NGO headquarters in 
capital. 

00:45 JOCC Director (Phone): Makes contact with host-nation command center(s) 
and local NGO headquarters to confirm receipt of information 

00:50 Phase 1 FINEX: Mini-UAV recovers. MECP Return to base. 
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APPENDIX B (COASTS EXPERIMENT SUMMARY) 


Key Excerpts Concerning Daytime Final Experiment Taken from 

COASTS 27 May 2008 Daily Sitrep 

PROGRAM MANAGER’S SUMMARY: 

The Cooperative Operations and Applied Science & Technology Studies (COASTS) 
International Field Experimentation Team conducted its final day of operations at Wing-5 on 
the Royal Thai Air Force (RTAF) Base in Prachuap Kliiri Khan on 27 May 2008. Two 
scenario runs were successfully conducted, one during the afternoon and one after dark. 
COASTS participants and observers numbered over one hundred (100) people representing 
the following organizations: 

• Royal Thai Defense Science & Technology Office 

• Royal Thai Air Force 

• Royal Thai Navy (RTN) 

• Royal Thai Navy SEALs 

• Royal Thai Naval Research & Development Office (NRDO) 

• Royal Thai Military Research & Development Center (MRDC) 

• RTN Engineering Officers School 

• Petroleum Authority of Thailand (PTT) 

• Electrical and Electronics Products Testing Center (PTEC) 

• Naval Postgraduate School (NPS) faculty and students 

• U.S. Special Operations Command (USSOCOM) 

• Defense Information Systems Agency (DISA) 

• Office of Naval Research (ONR) reservists 

• U.S. Army Training and Doctrine Command (TRADOC) Analysis 
Center/Engineering Research and Development Center (TRAC-ERDC) 

• U.S. Air Force 37th Security Forces Squadron 

• Naval Surface Warfare Center-Panama City Division (NSWC-PCD) 

• U.S. Marine Forces Pacific (MARFORPAC) 

• MARFORPAC Experimentation Center (MEC) 

• III Marine Expeditionary Force (MEF) 

• Joint U.S. Military Advisors Group Thailand (JUSMAGTHAI) 

• Embassy of Greece 

• Hellenic Air Force 

• Turkish Air Force 

• Numerous industry and commercial partners 

1. MAJOR ACCOMPLISHMENTS 

• Successfully ran all Scenario Phases (1, 2A, 2B, 3) during the day time using a 
compressed timeline. 

• Successfully ran Scenario Phases 2A and 2B during the night. 
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• Hosted several arriving VIPs including Lieutenant General Apichart (Director 
General DSTO), Major General Thitinant (Deputy Director General DSTO), Air 
Vice Marshal Wanchai (Special Projects Officer, DSTO), Air Vice Marshal 
Thanongsak (RTAF Security Force Command), Mr. Constantine Danassis 
(Deputy Head of Mission, Embassy of Greece) and Mr. Niyazi Evren Akyol 
(First Secretary, Turkish Embassy). 

2. KEY ISSUES 

• A power outage during the morning knocked the Digital Video Recorder out 
despite being connected to an Uninterrupted Power Supply (UPS). 

• CyberBug UAV was down and was not used in the experiment. 

• C-View Periscope is not functioning properly and was not used in the 
scenario. 

• One Compact Remote Imaging Sensing System with Two-7t+ OutLook 
(CRISSTL) Ball was broken during operations. 

***Skip 3, Jump to 4 

4. SYSTEMS STATUS 

4.1 Network 

a. Achievements 

• Network Team resuscitated the network and all associated systems from a 
JOCC power outage. 

4.1.A TwiddleNet 

a. Achievements 
•Phase 1: SUCCESS 

o Backhaul link: Good 

o Humanitarian Assistance site setup: SUCCESS 

■ Setup complete in less time allotted in scenario script. 

• Video / picture with data was received at JOCC . 

o Multithreading: SUCCESS 

■ All TwiddleNet handhelds were able to retrieve data from 
other handhelds. 

■ Pictures were displayed on server laptop for instantaneous 
streaming. 

• Radio Communications: SUCCESS 

• Thai counterparts as tsunami survivors: SUCCESS 

4.7.A Unmanned Air Vehicles (UAVs) 
a. Achievements 

• Video successfully transmitted through the AeroVironment (AV) 

Decoder application and displayed in the JOCC. Additionally, Axis web 
servers were used as well to display video via a web interface. 
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• Conducted two Raven UAV flights in support of the day/night scenario. 
Conducted one additional Raven flight after the night scenario in order to 
show additional IR capability. 

b. Near-Term Plans/Events 

• Nothing to report. 

c. Comments/Issues 

• During the day scenario a lost communication issue between the AU-23 
and the tower caused the Raven UAV to move into a holding pattern. In 
addition, a Citation aircraft made an emergency landing during the 
scenario. These issues impacted the loiter time by 10 minutes during the 
scenario. We have to ensure that contingencies/emergencies are cover in 
depth prior t launching in future field experiments. Specifically, all 
players need to be aware of contingency plans including scenario delay, 
hold position and altitude and recovery plans. 
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APPENDIX C (EQUIPMENT OPERATOR SURVEY) 


Questionnaire 

Performance Feedback on Specific Surveillance and 
Data Collection Platforms 


Principle Investigator : Captain Richard J. Bridgett, USMC, Student, GSBPP, NPS 

Project Title : Analysis of Specific Surveillance and Data Collection Platforms Used in 
Response to a Tsunami 

Background : In May of 2008, the NPS based Cooperative Operations and Applied 
Science and Technology Studies (COASTS), conducted their 5 th and final exercise of 
fiscal year 2008 in Ao Manao, Thailand. Ao Manao is located on the Thai Peninsula, on 
the gulf side, and is home to Wing 5 of the Royal Thai Air Force (RTAF). All 
experiments for exercise 5 were conducted aboard the RTAF base. 

Scenario 1 of exercise 5 (listed below) was an experiment that tested specific surveillance 
and data collection platforms with the purpose of giving the Joint Operations Center 
(JOC) an operational picture of the affected area. This operational picture was then 
transmitted to multiple emergency response and support agencies throughout the regional 
and international community allowing for a more efficient support effort. 

Task : Using the script below as an established guideline, please answer the questions 
that follow the script to the best of your recollection. The questions will cover the 
following areas: 

• Equipment tested 

• Time with regard to script 

• Problems encountered with the performance of the equipment 

• Problems encountered due to external factors 

• Additional comments 

***FEEL FREE TO USE EXCERPTS FROM TECHNICAL DOCS, IN¬ 
PROGRESS OR COMPLETED THESIS, ETC...ETC... THE MORE 
INFORMATION THE BETTER! 

For Script, reference Appendix A 

QUESTIONS BELOW I 
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QUESTIONS 

(use as much space as required to answer questions, the more the better!) 

1. Please provide in as much detail as possible a description of the equipment you tested 
and what its purpose was in the scenario 1 experiment. If applicable, please include 
technical specs, references, websites and any other resources which may help explain 
your answers. 


2. Please provide in a as much detail as possible an explanation as to how the equipment 
you tested compared to the timeline provided in the script above, i.e. the MECP took 
much longer to set up than the script depicted therefore throwing off the timeline, 
etc... and here is why... 


3. Please provide in as much detail as possible an explanation of any and all 
problems/issues you had with the equipment you were testing while the experiment was 
being conducted to include problems that prevented you from participating in the 
scenario 1 experiment or in portions of it. 


4. Please provide in as much detail as possible an explanation of any external problems 
(not related to equipment, i.e. weather, clearance from flight tower, etc...) that prevented 
you from participating in the scenario 1 experiment or in portions of it. 


5. Any additional comment. 


48 



APPENDIX D (ARENA SIMULATION MODEL: BASELINE ) 
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